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DETAILED ACTION 
Response to Amendment 

This Office Action is responsive to the amendment filed on 05/24/2010. 
Claims 1, 3 and 89 have been amended. 

Claim 90 has been canceled. 

Claims 1-8, 10-27, 33-37, 41-43, 45, 48, 51-52, 55-60, 62, 66-73, 79-82, 88-89 and 91-99 are 
pending in the application. 

Claim Rejections - 35 USC § 103 

1 . The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained iliough the eniion is noi ideiuieally diselosed or described as set forth in 
seetion 102 of this title, if the dit't'erenees between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

2. The factual inquiries set forth in Graham v. John Deere Co. , 383 U.S. 1 , 148 USPQ 459 
(1966), that are applied for establishing a background for determining obviousness under 35 
U.S.C. 103(a) are summarized as follows: 

1 . Determining the scope and contents of the prior art. 

2. Ascertaining the differences between the prior art and the claims at issue. 

3. Resolving the level of ordinary skill in the pertinent art. 

4. Considering objective evidence present in the application indicating obviousness 
or nonobviousness. 



1 . Claims 1-8, 10-27, 33-36, 88-98 rejected under 35 U.S.C. 103(a) as being unpatentable 
over Yaport et al. (US 2002/0178221 Al), hereinafter Yaport in view of Cai et al. (US 
2005/0030966 Al), hereinafter referred to as Cai. 
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Regarding claim 1 , Yaport discloses a method of multicasting a data file, (see title, abstract and 
fig.2), comprising: 

transmitting a notification on an upcoming multicast transmission to a plurality of 
receivers designated to receive the multicast transmission, (transmission: distribution for 
multicast data: [0033]-[0047], for notification, applicable to users of cellular phones, [0089], 
[0090]), 

transmitting a data file, (data is transmitted to the client 104), from a data server, 
([0033], [0036], [0037]: server 100), on the one or more multicast channels, (multicast data 
transmission means such as a router 102), without the data server receiving acknowledgements 
from the receivers on whether they received the notification, ([0035], [0042], [0081], [0088]: 
data transmission without client-server sessions and acknowledgement) 

determining, by the data server, at least one of the plurality of the receivers that received 
at least a portion of the data file, (the information is transmitted by portions, known as protocol 
data units: [0042] for delivery of small portions). 
Yaport does not explicitly disclose the steps of 

determining, by the data server, receivers designated to receive the multicast 
transmission that did not receive at least a portion of the data file 

attempting, by the data server, to deliver the data file to the determined receivers 
Cai teaches Multimedia Broadcast Multicast Service (MBMS) service where one use of MEMS 
services may be to broadcast an event that includes multiple communication sessions; With 
reference to fig. 3 and [0034], Cai teaches sending service announcement to subscribers MS 102- 
104 that subscribes to an MBMS service provided by communication system 100 participates in 
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an MBMS broadcast of an event. Cai further teaches, [0035], that when the MS does not desire 
to subscribe to the event, the MS does not respond to the announcement, other than, perhaps, to 
acknowledge receipt of the announcement. Thus as required Cai teaches that some of the 
subscribers may not have received the service announcement from the server 1 18. In addition 
Cai teaches, fig. 4A step 424, determining whether a second set of data (or portion of data) is 
received by the subscriber), [0048], [0052], that the MS has not previously received. Cai further 
discloses an attempt to deliver the data to the MS; for, [0054], by providing a Session 
Description in the sets of data packets conveyed to the MSs 102-104 associated with subscribers 
to the MBMS service and in an MBMS notification conveyed to the MSs, communication 
system 100 permits the MSs to determine whether to receive re-data broadcasts by the MBMS 
service 

It would have been obvious to a person of ordinary skill at the time the invention was made to 

implement Yaport with the teaching of Cai so that cHents can subscribe to a particular or selected 
multicast group at any time and missing data or replays of data to subscribers is provided. 
Regarding claim 2 . Yaport discloses transmitting the notification comprises transmitting on a 
multicast or broadcast channel, [0031] 

Regarding claim 3. Yaport discloses transmitting the notification comprises transmitting a 
unicast notification to each of the receivers on the designated receivers, ([0020]: fig. 1 is a very 
schematic representation of an existing system for unicast connection) 
Regarding claim 4. Yaport discloses transmitting the notification comprises transmitting 
substantially only to designated receivers, (by sending multicast data to members of the 
multicast group: the users who agree with the service provider or operator on the conditions 
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regarding the provision of the multicast service and who indicate willingness or readiness to 
receive the multicast service are the designated receivers, [0040]). 

Regarding claim 5. Yaport discloses transmitting the notification comprises transmitting a 
message open also to non-designated receivers, (the multicast data source is the server 100 (figs. 
6-9) assuring Multimedia Broadcast Multicast Service (MBMS); thus in the broadcast mode the 
data is transmitted to all users in one or more broadcast areas, (this includes also non-designated 
receivers). 

Regarding claim 6. Yaport discloses the notification indicates the one or more channels on 
which the multicast transmission will be provided, ([0090] the immediate notification indicates 
that one client may have capability of receiving the selected information in parallel mode but via 
several different speed channels simultaneously). 

Regarding claim 7. Yaport discloses tuning to the multicast channel by at least one of the 
receivers comprises determining by each receiver that receives the notification whether to tune 
onto the one or more multicast channels, ([0090]) 

Regarding claim 8. Yaport discloses determining by each receiver that receives the notification 
whether to tune onto the one or more multicast channels comprises determining, from the 
notification, a group to which the upcoming multicast transmission belongs and determining 
whether to tune onto the one or more multicast channels according to the determined group, 
(note group can vary depending on the nature of the service, any client can subscribe to a 
particular multicast group for receiving the data; for example reference numeral 44 is the 
Intemet, and 42-1, 42-2, 42-3 are clients of group 42; 40-1, 40-2 are chents of group 40, etc.). 
Regarding claim 10. Yaport discloses determining by each receiver that receives the notification 
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whether to tune onto the one or more multicast channels comprises determining based on input 
received from a user responsive to the notification, ([0063]: the client 104-1 receives the 
randomly selected initial PDU in response to the request Rl, as "On Demand" attempt to 
transport the program or show from a central repository (server) to the user (client) in response to 
his/her request. To initiate the request, the user selects from a list of candidate programs and 
requests that the system deliver the selected program.). 

Regarding claim 11. the receivers do not transmit acknowledgements of reception of the 
notification, at all, (Yaport discloses, [0017], [0081], [0088]: connection is confirmed by 
acknowledgement, and the data is transmitted to the client 26-1 via the established connection; 
Regarding claim 12. Yaport does not explicitly disclose that the receivers cannot transmit uplink 
messages to the data server, without stopping to listen to the one or more multicast channels. 
Cai discloses [0028] uplink 135 that includes multiple communication channels, comprising 
[0031], one or more of muUiple time slots in a same frequency bandwidth. 
Therefore, it would have been obvious to a person of ordinary skill at the time the invention was 
made to implement Yaport with the teaching of Cai so that receivers can particularly select one 
or more multicast group. 

Regarding claim 13. attempting to deliver the data file comprises delivering the data file in a 

unicast transmission to each of the determined receivers. 

Yaport discloses data distribution over the channels of one of the channel groups, e.g., 130, so as 
to fransfer to clients of a particular group of multicast groups, [0031] for, a plurality of individual 
sessions occurs between individual clients and the server(s) consisting of unicast fransmission: 
[0014], [0016], [0020]. 
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Regarding claim 14. attempting to deliver the data file comprises delivering the data file in a 
multicast transmission to a plurality of the determined receivers, (by sending multicast data to 
members of the multicast group: the users who agree with the service provider or operator on the 
conditions regarding the provision of the multicast service and who indicate willingness or 
readiness to receive the multicast service are the designated receivers). 
Regarding claim 15. attempting to deliver the data file comprises providing a notification 
message inviting the receivers to download the transmission on a unicast connection, to the 
determined receivers. 

Yaport discloses data distribution over the channels of one of the channel groups, e.g., 130, so as 
to transfer to clients of a particular group of multicast groups, [003 1] for, a plurality of individual 
sessions occurs between individual clients and the server(s) consisting of unicast transmission: 
[0014], [0016], and [0020]. 

Regarding claim 16 , at least 80% of the designated receivers establish only a single unicast 
connection related to receiving the data file. 

Yaport discloses data distribution over the channels of one of the channel groups, e.g., 130, so as 
to transfer to clients of a particular group of multicast groups, [0031] for, a plurality of individual 
sessions occurs between individual clients and the server(s) consisting of unicast transmission: 
[0014], [0016], [0020]. 

Regarding claim 17, substantially all of the designated receivers establish only a single unicast 
connection related to receiving the data file. 

Yaport discloses data distribution over the channels of one of the channel groups, e.g., 130, so as 
to transfer to clients of a particular group of multicast groups, [0031] for, a plurality of individual 
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sessions occurs between individual clients and the server(s) consisting of unicast transmission: 
[0014], [0016], [0020]. 

Regarding claim 18. all of the designated receivers establish up to two single unicast 
connections related to receiving the data file. 

Yaport discloses data distribution over the channels of one of the channel groups, e.g., 130, so as 
to transfer to clients of a particular group of multicast groups, [003 1] for, a plurality of individual 
sessions occurs between individual clients and the server(s) consisting of unicast transmission: 
[0014], [0016], [0020]. 

Regarding claim 1 9 , Yaport does not explicitly disclose at least a portion of the data file is 
encrypted, requiring one or more decryption keys identified in the transmitted data file. 
Cai discloses [0020], [0030], [0036], [0050] a keypad that includes multiple keys via which a 
user of the MS may input an instruction to the MS. Therefore, it would have been obvious to a 
person of ordinary skill at the time the invention was made to implement Yaport with the 
teaching of Cai so as to conveys a response to server 118 indicating a desire of a user of the MS 
to subscribe to the event. 

Regarding claim 20. Yaport does not explicitly disclose the receivers request the one or more 
keys after receiving the data file. 

Cai discloses [0020], [0030], [0036], [0050] a keypad that includes multiple keys via which a 
user of the MS may input an instruction to the MS. Therefore, it would have been obvious to a 
person of ordinary skill at the time the invention was made to implement Yaport with the 
teaching of Cai so as to conveys a response to server 118 indicating a desire of a user of the MS 
to subscribe to the event. 
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Regarding claim 21 , Yaport does not explicitly disclose at least one of the receivers requests the 
one or more keys, 

Cai discloses a keypad that includes multiple keys [0020], [0030], [0036], [0050], that the user 
may select or a key of a keypad that a user may depress to generate a response. 

Therefore, it would have been obvious to a person of ordinary skill at the time the invention was 
made to implement Yaport with the teaching of Cai so as to conveys a response to server 118 
indicating a desire of a user of the MS to subscribe to the event. 

Regarding claim 22. Yaport does not explicitly disclose the receivers request the one or more 
keys after determining that they received sufficient data to allow reconstruction of the data file, 
Cai, [0050], discloses that the retrieved message may instruct the user to select one key of a 
keypad if the user's response is affirmative and to select another key of the keypad if the user's 
response is negative; therefore, the retrieved message is thus displayed by processor 206 and the 
message is retrieved (reconstructed) on the display screen of user interface 210. 
Therefore, it would have been obvious to a person of ordinary skill at the time the invention was 
made to implement Yaport with the teaching of Cai so as to conveys a response to server 118 
indicating a desire of a user of the MS to subscribe to the event. 

Regarding claim 23. Yaport discloses the claimed invention except that the keys are received on 
a single unicast connection along with any supplementary data required, not received during the 

multicast transmission. 

Yaport discloses the supplementary data reception, (PDUCl, PDUC2: they are intended for 
improving rehability of data transmission, [0045]-[0046]; data distribution over the channels of 
one of the channel groups, e.g., 130, so as to transfer to clients of a particular group of multicast 
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groups, [003 1] for, a plurality of individual sessions occurs between individual clients and the 
server(s) consisting of unicast transmission: [0014], [0016], [0020]. 

Regarding claim 24. Yaport does not explicitly disclose the steps of receiving acknowledgements 
from receivers that received the notification or at least a portion of the data file, after 

transmitting the data file, wherein determining receivers designated that did not receive at least 
a portion of the data file is performed by determining receivers from which acknowledgments 
were not received. 

Cai teaches Multimedia Broadcast Multicast Service (MBMS) service where one use of MBMS 
services may be to broadcast an event that includes multiple communication sessions, that is to 
transmit portion of the data for providing missing data or replays of data to subscribers. Cai 
teaches, fig. 4A step 424, determining whether a second set of data (or portion of data) is 
received by the subscriber), [0048], [0052], that the MS has not previously received. Cai further 
discloses an attempt to deliver the data to the MS; for, [0054], by providing a Session 
Description in the sets of data packets conveyed to the MSs 102-104 associated with subscribers 
to the MBMS service and in an MBMS notification conveyed to the MSs, communication 
system 100 permits the MSs to determine whether to receive re-data broadcasts by the MBMS 
service 

It would have been obvious to a person of ordinary skill at the time the invention 
was made to implement Yaport with the teaching of Cai so that clients can subscribe 
to a particular or selected multicast group at any time and missing data or replays of data to 

subscribers is provided. 
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Regarding claim 25 , Yaport does not explicitly disclose receiving the acknowledgements 
comprises receiving a request for decryption keys. 

Cai discloses, with reference to fig. 3 step 308 and [0035], that a MS responds to server 
1 18 to service announcement (acknowledging desire to subscribe), and, [0036], included in the 
response is the mobile ID uniquely associated with the MS, allowing server 1 18 to determine the 
source of the response. Therefore, [0037]-[0038], server 118 produces identifier (ID) enabling 
the subscribers to view the event. 

Therefore, it would have been obvious to a person of ordinary skill at the time the 
invention was made to implement Yaport with the teaching of Cai for subscribers to request 
decryption key to purchases desired multimedia program or software that are of interest to them. 

Regarding claim 26. receiving the acknowledgements comprises receiving a request for 

supplementary data not received during the multicast transmission. 

Yaport discloses receiving multicast data in the form of protocol data units PDUl, PDU2, PDU3, 
PDU4 , so that if any informational PDU such as PDUCl, PDUC2 ... is lost during the 
transmission, the control protocol data units of all data segments will allow to restore the missing 
data , [0046]. 

Regarding claims 27 , receiving the acknowledgements comprises receiving over a different 
network than the network on which the data file was multicast. 

Yaport discloses, [0017], data sessions are occurring between clients and the servers with 
confirmation of data reception (acknowledgment) so that an established connection when failed, 
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another connection is established thus through different network for, [0089]: for example, the 
wide area network is not necessary is the Internet and may be any other wide area 
network. 

Regarding claim 33. attempting to deliver the data file to the determined receivers comprises 
delivering on a different network than the network on which the data file was multicast. 
Cai teaches, fig. 4A step 424, determining whether a second set of data (or portion of data) is 
received by the subscriber), [0048], [0052], that the MS has not previously received. Cai further 
discloses an attempt to deliver the data to the MS; for, [0054], by providing a Session 
Description in the sets of data packets conveyed to the MSs 102-104 associated with subscribers 
to the MBMS service and in an MBMS notification conveyed to the MSs, communication 
system 100 permits the MSs to determine whether to receive re-data broadcasts by the MBMS 
service 

It would have been obvious to a person of ordinary skill at the time the invention was made to 
implement Yaport with the teaching of Cai so that clients can subscribe to a particular or selected 

multicast group at any time and missing data or replays of data to subscribers is provided. 
Regarding claim 34 . the notification indicates a plurality of categories to which the data file 
relates and the plurality of receivers comprises receivers designated to receive data belonging to 
different ones of the plurality of categories, (Y aport discloses capability of receiving the selected 
information or notification in parallel mode but via several different speed channels 
simultaneously, [0090]: this indicates the plurality of categories relates such as text, audio, video, 
and interlaced computer programs; [0005]) 
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Regarding claim 35. transmitting the data file comprises transmitting a plurality of sub-files in a 
plurality of separate transmission sessions, ([0035]: file is divided into data segments, the data 
segments are distributed between data transmission units 114 and 116: [0037]) 
Regarding claim 36. transmitting the data file comprises transmitting a plurality subfiles on a 

plurality of different channels. 

Yaport discloses the data segments are distributed between data transmission units 1 14 and 116: 
[0037]). 

Regarding claim 88. Yaport discloses a data server, (figs. 6-9 server 100), comprising: 

an input interface for receiving files to be multicast, ([0033]: as shown in this drawing, the 
system of the invention, as an existing system of FIG. 2, consists of a server 100, a multicast data 
transmission means such as a router 1 02, groups of clients 1 04- 1 , 1 04-2, 1 04-3 ... 1 04-n with 
respective routers 106-1,106-2,106-3, . . . 106-n and the Intemet 107 located between the routers 
ofthe groups of clients 104-1,104-1,104-3 . . . 104-n and the router 102); 

an output interface for providing signals for transmission to receivers, ([0033]), 
Yaport discloses a data transmission server 100 for multicast data transmission, (fig. 2), [0031], 
[0032], [0035], to recipients without acknowledgment, thus [0035], [0047]: the multicast 
distribution does not need confirmation: the server 100 and the method of multicast data 
transmission without cUent-server sessions and acknowledgement). In addition Yaport teaches 
that information is transmitted by portions, known as protocol data units, [0044]. In addition, 
[0046], the control protocol data units of all data segments will allow to restore the missing data 
(portion of the data or PDU such as PDUCl, PDUC2) lost during the transmission. 



Application/Control Number: 10/574,240 Page 14 

Art Unit: 2472 

Yaport does not disclose an input interface, an output interface, and a controller as required by 
the claim. 

Cai discloses a server 118 coupled to a RAN controller 1 14 via a support node receives a first set 
of MBMS data from an MBMS content provider, [0020], 

a controller ([0040]: fig. 1, the Radio Access Network further comprises Radio Network 
Controllers (RNC) 1 14), adapted to generate a notification on an upcoming multicast 

transmission, (a multicast service notification is transmitted to mobile stations, thereby 
informing members of the multicast group of an upcoming multicast sessions), responsive to a 
received file, to provide the notification through the output interface for transmission and to 
provide the received file for transmission, (notifying the mobile stations of incoming multicast 
data), without receiving acknowledgements from the receivers on whether they received the 
notification, to determine receivers designated to receive the multicast transmission that did not 
receive at least a portion of the data file and to attempt to deliver the data file to the determined 
receivers. 

Therefore, it would have been obvious to a person of ordinary skill at the time the invention was 
made to implement Yaport with the teaching of Cai so that clients can subscribe to a particular or 

selected multicast group at any time. 

Regarding claim 89 , Yaport describes a mobile station, ([0089]: users of cellular phones: not 
shown) comprising: 

a receiver, and 
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a processor adapted to tune the receiver to receive data on a plurality of multicast 
channels and to combine the data received on the plurality of channels into a single multimedia 
file, 

Yaport however does not disclose a receiver and a processor as required by the claim. 

Cai discloses a mobile station shown in fig. 1 and further in a block diagram of fig. 2, 
comprising a receiver 202, and a processor 206. Furthermore, Cai teaches that the processor 

receives a plural sets of MBMS data, [0023]. The system assures a transmission (or rebroadcast 
of a Multimedia Broadcast Multicast Service (MBMS) service to the subscribers). 

Therefore, it would have been obvious to a person of ordinary skill at the time the invention was 
made to implement Yaport with Cai, to allow data to be transmitted from a single source point to 
multiple endpoints. 

Regarding claim 90 , Yaport discloses the data received on the plurality of channels, ([0043], and 
fig. 4), comprises different multimedia types on different channels. 

Regarding claim 9 1. determining the receivers that did not receive at least a portion of the data 
file comprises determining receivers that did not receive the data file at all. 
Yaport teaches the claimed invention except explicitly determining the receivers that did not 
receive at least a portion of the data file comprises determining receivers that did not receive the 
data file at all. 

Cai teaches Multimedia Broadcast Multicast Service (MBMS) service where one use of MBMS 

services may be to broadcast an event that includes multiple communication sessions, that is to 
transmit portion of the data for providing missing data or replays of data to subscribers. Cai 
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teaches, fig. 4A step 424, determining whether a second set of data (or portion of data) is 
received by the subscriber), [0048], [0052], that the MS has not previously received. Cai further 
discloses an attempt to deliver the data to the MS; for, [0054], by providing a Session 
Description in the sets of data packets conveyed to the MSs 102-104 associated with subscribers 

to the MBMS service and in an MBMS notification conveyed to the MSs, communication 
system 100 permits the MSs to determine whether to receive re-data broadcasts by the MBMS 
service. 

It would have been obvious to a person of ordinary skill at the time the invention was made to 

implement Yaport with the teaching of Cai so that clients can subscribe to a particular or selected 
multicast group at any time and missing data or replays of data to subscribers is provided. 

Regarding claim 92. transmitting a data file on the one or more multicast channels comprises 
transmitting the file data a plurality of times, (Y aport teaches [0037]: data or information is 
divided into a plurality of data segments allowing for a plurality of individual sessions occurring 

between individual clients and the server(s)). 

Regarding claim 94. Yaport teaches providing the notification message comprises sending a 
message to a mail-box of the mobile station, (two-way data communication between the 
browsing user, who has a specific electronic address or destination, and the web page, which also 
has a specific electronic destination: [006]) 

Regarding claim 95 , Yaport teaches the claimed invention except explicitly the notification 

message comprises providing in an SMS message. 

Cai discloses,[0037], [0037] that the service announcement may be sent in any over-the-air 
format, such as via a broadcast over paging channel 131, via a short message service (SMS), or 
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via a multicast. It would have been obvious to a person of ordinary skill at the time the invention 
was made to modify Yaport with the teaching of Cai for integration of SMS message allowing 
the interchange of short text messages. 

Regarding claim 96. at least 80% of the designated receivers establish only a single unicast 
connection related to receiving the data file and transmit only a single request for data. 
Yaport discloses data distribution over the channels of one of the channel groups, e.g., 130, so as 
to transfer to clients of a particular group of multicast groups, [0031] for, a plurality of individual 
sessions occurs between individual clients and the server(s) consisting of unicast transmission: 
[0014], [0016], [0020]. 

Regarding claim 97. the receivers transmit uplink transmissions regarding the multicast 
transmission only after they collected from the multicast channel all the data from the multicast 
channel used in reconstruction the multicast transmission. Cai discloses [0028] uplink 135 that 
includes multiple communication channels, comprising [0031], one or more of multiple time 

slots in a same frequency bandwidth. 

Therefore, it would have been obvious to a person of ordinary skill at the time the invention was 
made to implement Yaport with the teaching of Cai so that receivers can particularly select one 
or more multicast group 

Regarding claim 98. Yaport does not explicitly discloses that at least one of the receivers 
requests the one or more keys from an entity belonging to a different mobile network, 

Cai discloses (multiple softkeys such softkeys corresponding to keys on a conventional telephone 
keypad: [0030], [0036]). Therefore, it would have been obvious to a person of ordinary skill at 
the time the invention was made to implement Yaport with the teaching of Cai so that receivers 
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can particularly select one or more multicast group so as to provide a response to server 
indicating a desire of a user of the MS to subscribe to the event). 

2. Claims 37, 41 and 42 rejected under 35 U.S.C. 103(a) as being unpatentable over Xu et 
al. (US 2006/0166653 Al), in view of Halter et al. (US 5,319,705) hereinafter Halter. 

Regarding claim 37. Xu teaches a method of receiving a data file provided in a multicast 
transmission, (fig. 2 multicast data reception step 218), comprising: 

tuning, by a mobile station, onto a multicast channel, (fig. 1 and [0038] the message to 
inform the MS of upcoming multicast session: note fig. 3 step 308. When this notification 
arrives, the mobile station changes to the multicast reception mode, (tune) where it listens to the 
MBMS data channel in order to receive the service data (step 308) transmitted on that channel, 
[0060], [0061]); 

However Xu does not explicitly teach 

receiving at least one encrypted packet which can be used in reconstructing the data file, 
receiving at least one key required for decrypting the at least one packet after receiving a 
sufficient number of packets for reconstructing the data file. 

Halter, in the same field teaches (fig. 3, col. 7 lines 63-68 and col. 8 lines 1-25) a 
subscriber (user processor 20) receiving an encrypted file from software distribution processor 
10 via an encrypted file distribution medium 30. Subsequent to the receiving of the file, 
cryptographic keys are distributed from software distribution processor 10 to user processor 20 
using a key distribution medium 3 1 . 
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Therefore, it would have been obvious to a person of ordinary skill at the time the 
invention was made to implement Xu with the teaching of Halter so that a client (a subscriber) 
receives a decryption key independently delivered via the U.S. postal service or similar delivery 
service such as Federal Express or, via a telephone connection permitting the keys to be 
delivered orally to the user or automatically where the user is not required to write keys down on 
paper or to enter keys using a key-pad, and for the subscribed document for which only he or she 
is charged. 

Regarding claim 41. Xu teaches the claimed invention except explicitly 

requesting the at least one key after receiving a sufficient number of packets for reconstructing 
the data file and wherein receiving the at least one key is performed responsive to the requesting. 

Halter teaches that, col. 9 lines 28-30: for each encrypted file transmitted via file 
distribution medium 30, there is an encrypted data key transmitted via key distribution medium 
3 1 . Furthermore, Halter teaches that, lines 33-37: a data key can be associated with one or more 
encrypted files. 

Therefore, it would have been obvious to a person of ordinary skill at the time the 
invention was made to implement Xu with the teaching of Halter so that a subscriber could 
access software or a multimedia file consisting of several files or multimedia files. 

Regarding claim 42. Xu teaches the claimed invention except explicitly 

the requesting of the at least one key is performed responsive to a user instruction. 
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Halter teaches that, a request will be transmitted from the user processor to the software 
distribution processor. In response to that request, an encrypted file encryption key specific for 
the requested file, will be transmitted to the user processor: (abstract, and col. 8 lines 26-34) 

Therefore, it would have been obvious to a person of ordinary skill at the time the 
invention was made to implement Xu with the teaching of Halter, enabling subscribers to 
purchase multimedia program or software to access encrypted software or a multimedia files. 

3. Claims 43, 45, 48, 5 1 , 52, and 55 rejected under 35 U.S.C. 103(a) as being unpatentable 
over Xu in view of Halter and further in view of Dillon (6,728,878). 

Regarding claims 43. 45 . at least a portion of the data file is not encrypted and the user 

instruction is received after displaying the non-encrypted portion of the file to the user. 
Xu and Halter teach receiving an encrypted data and the key, Xu in view of Halter does not 
explicitly teach that 

a portion of the data file is not encrypted, 

the non-encrypted portion of the file is received before any encrypted portion of the data 

file 

Dillon in the same field discloses, fig. 1, communications link 140 includes an incoming 
link 142 canying encrj^ted and non-encrypted data packets to the file broadcast receiver 1 12 in 
the receive computer 110; the non-encrypted data packets representing a catalogue. Furthermore, 
with reference to fig. 5, after receiving computer 10 receives the catalog (unencrypted), the user 
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sends a load request instruction as shown on the timing diagram. As shown, the catalog 
(unencrypted) is received before the reception of the document. 

Therefore, it would have been obvious to a person of ordinary skill at the time the 
invention was made to implement Xu and Halter with Dillon for purchasing software or 

multimedia documents of their choice, by selecting from provider catalog. 
Regarding claim 48. the file includes a plurality ofdijferent portions requiring different keys for 
decryption and wherein the keys required for at least one portion are received after displaying at 
least one other portion. 

Although Xu and Halter teach receiving an encrypted data, Xu in view of Halter does not 
explicitly teach that the file includes a plurality of different portions requiring different keys for 
decrj^tion and wherein the keys required for at least one portion are received after displaying at 
least one other portion. 

Dillon teaches that, col. 7 lines 66-67 and col. 8 lines 1-: each document sent from 
broadcast center 150 is decrypted with a different key. If broadcast receiver 120 has received a 
correct key from security engine 130, it decrypts the packet and passes it to file broadcast 
receiver 112, where the packets of the received document are assembled in their correct order 
and stored in memory 404, e.g., on a hard disk. 

Therefore, it would have been obvious to a person of ordinary skill at the time the 
invention was made to implement Xu and Halter with Dillon to purchase software or multimedia 
documents by order of selection. 

Regarding claims 51. 52 and 55 . tuning onto the multicast channel is performed responsive to 
receiving a notification on an upcoming multicast transmission and responsive to a 
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determination that the upcoming multicast transmission matches a subscription profile of the 
receiver, 

Xu in view of Halter teach the claimed invention explicitly notification on an upcoming 
multicast transmission and multicast transmission matches a subscription profile of the receive, 

and the determination that the upcoming multicast transmission matches a subscription 
profile of the receiver comprises consulting a multicast subscription profile stored on the 
receiver, and 

acknowledging receipt of the at least one key, in a manner which allows charging for the 

data file, 

Dillon teaches a notification (announcement message from the broadcast center) that 
matches the receiver's interest stored in memory 404; the receiving computer decrypts the 
document and stores billing information, (fig. 5), about the received document and the billing 
information is transferred back to the broadcast center (acknowledgement) at a later time: in step 
802 of FIG. 7(a), file broadcast receiver 1 12 receives the announcement message for a document 
and, in step 804, determines whether the document ID in the announcement message is contained 
in the list of documents of interest in memory 404. If so, file broadcast receiver 1 12 sends a load 
request to security engine 130 in step 806. The load request contains, e.g., the document ID from 
the announcement message, so that secmty engine 130 can send a corresponding key to 
broadcast receiver 120. 

Therefore, it would have been obvious to a person of ordinary skill at the time the 
invention was made to implement Xu and Halter with Dillon to purchase software or multimedia 
documents by order of interest. 
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4. Claims 56 rejected under 35 U.S.C. 103(a) as being unpatentable over Xu, in view of 
Halter. 

Regarding claim 56 , Xu discloses a method of multicasting a file, comprising: 

encrypting the file using one or more keys, ([0071]: a different signing key can be 
provided for each authorized mobile station (source authentication) or the same signing key can 
be shared by all authorized mobile stations (group authentication)); 

transmitting the enciyptedfile to a plurality of receivers in a multicast transmission, 
(note a message authentication code (MAC) is included in the transmitted message, therefore the 
need for a key distribution center (KDC) ensures that different signing key can be provided for 
each authorized mobile station to decrypt the encrypted file, [0069]-[0072])); 
and providing at least one of the plurality of receivers with one or more decryption keys required 
for decrypting the transmitted encrypted file, after the file was transmitted, (the mobile station 
obtains a signing key (signing keys provided to the mobiles, from the KDC, for the purpose of 
decrypting the file, [0071]-[0074]). Note fiirther that [0068], a Message Authentication Code 
(MAC) can be included in a message to provide authenticity without secrecy. The MAC is a 
value derived from the message by a key-dependent one-way function (such as the widely used 
HMAC). Only the party possessing the key can create or verify the MAC, thus showing that the 
key is provided after the message is received. 

Although Xu teaches the message, Xu does not explicitly teach providing decryption keys after 
the file was transmitted. 
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Halter teaches (fig. 3, col. 7 lines 63-68 and col. 8 lines 1-25) a subscriber (user processor 
20) receiving an encrypted file from software disfribution processor 10 via an encrypted file 
distribution medium 30. Subsequent to the receiving of the file, cryptographic keys are 
distributed from software distribution processor 10 to user processor 20 using a key distribution 

medium 3 1 . 

Therefore, it would have been obvious to a person of ordinary skill at the time the 
invention was made to implement Xu with Halter so that a client (a subscriber) receives a 
decryption key independently delivered via the U.S. postal service or similar delivery service 
such as Federal Express or, via a telephone connection permitting the keys to be delivered orally 
to the user or automatically where the user is not required to write keys down on paper or to 
enter keys using a key-pad, and for the subscribed document for which only he or she is charged. 

5. Claims 57-60 and 62 rejected under 35 U.S. C. 103(a) as being unpatentable over Xu, in 
view Halter and further in view of Majmundar et al. (US 200600225123 Al) hereinafter 
Majmundar. 

Regarding claims 57 and 58 providing at least one of the receivers with at least one decryption 
key for the encrypted file, before transmitting the encrypted file, 

Xu teaches the multicast fransmission. However does not teach explicitly providing the 
decryption key before transmitting the encrypted file. 

Halter teaches transmitting decryption key, however does not teach transmitting the key 
before the transmitting the encrypted file. 
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Majmundar, in the same field teaches transmitting encrypted data with the host 
transmitting the decryption key before or after the download: [[0030]: download data may be 
transmitted in encrypted form, and the host may transmit a decryption key to each terminal 
device that is supposed to receive the download data, perhaps ... at some other time before of 
after the download data. 

With regards to claim 58, receiving from the at least one receivers provided with the 
decryption keys before transmitting the encrypted file, acknowledgement messages, 

Majmundar fiirther teaches [0030] that terminal devices may acknowledge receipt only 
after successfully decrypting the download data. 

Therefore, it would have been obvious to a person of ordinary skill at the time the 
invention was made to implement Xu with Halter and fiirther with Majmundar to provide all 
subscribers with decryption key independently delivered via the U.S. postal service or similar 
delivery service such as Federal Express or, via a telephone connection permitting the keys to be 
delivered orally to the user or automatically where the user is not required to write keys down on 
paper or to enter keys using a key-pad. 

Regarding claim 59. Xu discloses the acknowledgement messages are received at least 10 
minutes after the transmission of the encrypted file is completed, (note, [0051] discloses the 
moment for the response to the membership query is determined by setting a timer to a random 
value between zero and the maximum delay value. The idea here is to determine a member- 
specific response moment for each group member present in the cell. The response moment can 
be determined in many different ways. Instead of setting a timer to a random value, each mobile 
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station can, for example, calculate its response moment by means of an algorithm having at least 
one input specific to each mobile station) 

Regarding claim 60. Xu discloses the at least one of the receivers provided with the decryption 
keys before transmitting the encrypted file are selected at least partially responsive to previous 
behavior of the receivers, (note fig. 3 step 308: {responsive to the notification), when this 
notification arrives, the mobile station changes to the multicast reception mode, where it listens 
to the MBMS data channel in order to receive the service data (step 308) transmitted on that 
channel, [0060]; in addition, [0061], [0071], a different signing key, (decryption keys), can be 
provided for each authorized mobile station before the transmission of the encrypted file). 
Regarding claim 62. the at least one of the receivers provided with the decryption keys before 
transmitting the encrypted file are selected at least partially responsive to the number or 
percentage of acknowledgements provided by the receivers in a given period, 

Xu teaches the muhicast transmission, However does not teach explicitly to the number 
or percentage of acknowledgements provided by the receivers in a given period. 

Halter teaches transmitting decryption key, however does not teach to the number or 
percentage of acknowledgements provided by the receivers in a given period, 

Majmundar teaches [0030] decryption key before or after the download and terminal 
devices may acknowledge receipt only after successfully decrypting the download data 

Therefore, it would have been obvious to a person of ordinary skill at the time the 
invention was made to implement Xu with Halter and fiirther with Majmundar to provide 
retransmission of data until successfiil decryption. 
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6. Claims 79, 82 rejected under 35 U.S.C. 103(a) as being unpatentable over Siren 
(2002/0006801 Al) in view Sasvari et al. (US 2004/0057376 Al) hereinafter Sasvari. 

Regarding claim 79. Siren discloses a method of transmitting multicast data in a cellular 
network, comprising: 

providing data for multicast transmission, ([0046], [0047], [0049], [0050]), to a plurality 
of base stations, having different bandwidth amounts for multicast transmission, at a same rate 
([0035]: different bandwidth allocation to a plurality of base stations in a wireless network to 
assure group or multicast transmission over the wireless network), 
Siren teaches the claimed invention except explicitly 

dropping data by one or more of the base stations, as required, so that the data can be 
transmitted by each of the base stations on its respective allocated bandwidth for multicast 
transmission; and 

transmitting the non-dropped data such that the data is transmitted by all the base stations 
substantially synchronously. 

Sasvari discloses, [0011], [0023], in a communications system a finite bandwidth for the 
communication of traffic of a plurality of users; the communications system further comprises 
packet discard means for discarding (or dropping) packets, on an individual basis, in a pseudo- 
random fashion so that data transmitted by individual user to the system has a finite bandwidth 
for canying the traffic; 
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Therefore, it would have been obvious to a person of ordinary skill at the time the invention was 
made to modify Siren with the teaching of Sasvari, to maintain the communication of traffic of a 
plurality of users in which the system has a finite bandwidth for carrying the traffic. 

Regarding claim 82. Siren discloses transmitting supplementary data to receivers that request 
data they did not receive in the multicast transmission over point-to-point connections, ([0035] 
channels allocated to individual point-to-point user channels having a single recipient). 



7. Claim 80 rejected under 35 U.S.C. 103(a) as being unpatentable over Siren in view 
Sasvari and further in view of Okada (US 2002/0012327 Al). 

Regarding claim 80. Siren discloses the base stations except explicitly: 

the base stations use a small buffer, having room for at most five packets, for the 
provided multicast data, 

Okada discloses, fig. 25, a base station 2501, as a general base station that includes a 
forwarding unit 2505 which has a buffer 2504 for forwarding to a multicast address. [0223]- 
[0225]: the buffer stores packets which is transmitted or forwarded to other locations. Therefore, 
it would have been obvious to a person of ordinary skill at the time the invention was made to 
modify Siren in view of Sasvari with the teaching of Okada to maintain flow performance based 
on the buffer state of the base station. 
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8. Claims 81 and 99 rejected under 35 U.S.C. 103(a) as being unpatentable Siren in view 
Sasvari and further and further in view of Tasman et al (2002/0080755 Al). 

Regarding claims 81 and 99 . Siren in combination of Sasvari teach the claimed invention except 
explicitly providing the data, comprises providing data protected with a forward error 
correction code, 

Tasman, by disclosing that communication occurs from the server to the client without 
acknowledgement or confirmation, many telephone and computer communication channels 
presume that data is lost if no acknowledgement is received and retransmit the lost data, resulting 
in forward error correction. It would have been obvious to a person of ordinary skill at the time 
the invention was made to modify Siren with Tasman to incorporate forward error correction 
(FEC), for (FEC) software may reduce the number of retransmissions by alleviating some 
portion of the data packet loss. 



9. Claim 93 rejected under 35 U.S.C. 103(a) as being unpatentable over Yaport in view of 
Cai and fiirther in view of Tasman et al. (US 2002/0080755 Al). 

Regarding claim 93, transmitting the data file comprises transmitting the file protected with a 
forward error correction code. 
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Yaport teaches the claimed invention except explicitly transmitting the file protected with a 
forward error correction code. 

Tasman, [0048], in disclosing a mechanism for forwarding layer interfacing for networks, 
teaches encoding resulting in forward error correction (FEC). It would have been obvious to a 
person of ordinary skill at the time the invention was made to modify Yaport with Tasman to 
incorporate forward error correction (FEC), for (FEC) software may reduce the number of 
retransmissions by alleviating some portion of the data packet loss. 

Allowable Subject Matter 

10. Claims 66-73 are allowed. 



Response to Arguments 

Regarding claim 79 

Applicant argues that "base stations having different bandwidth amounts for multicast 
transmission, dropping data so that the data can be transmitted by each of the base stations on its 
respective allocated bandwidth and transmitting the non-dropped data substantially 
synchronously" is not taught or suggested by Siren or Sasvari. 

Examiner submits that providing data formulticast transmission, ([0046], [0047], [0049], 
[0050]), to a plurality of base stations, having different bandwidth amounts for multicast 
transmission, at a same rate ([0035]: different bandwidth allocation to a plurality of base stations 
in a wireless network to assure group or multicast transmission over the wireless network). 
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Siren teaches the claimed invention except explicitly 

dropping data by one or more of the base stations, as required, so that the data can be 
transmitted by each of the base stations on its respective allocated bandwidth for multicast 
transmission; and 

transmitting the non-dropped data such that the data is transmitted by all the base stations 

substantially synchronously. 

Sasvari discloses, [001 1], [0023], in a communications system a finite bandwidth for the 
communication of traffic of a plurality of users; the communications system further comprises 
packet discard means for discarding (or dropping) packets, on an individual basis, in a pseudo- 
random fashion so that data transmitted by individual user to the system has a finite bandwidth 
for carrying the traffic; As required, the drop affects each user's device separately so as to 
maintain the same transmission rate to achieve synchronous transmission. 

Regarding claims 88 and 89 . 

Yaport discloses a data server, (figs. 6-9 server 100), comprising: 

an input interface for receiving files to be multicast, ([0033]: as shown in this drawing, the 
system of the invention, as an existing system of FIG. 2, consists of a server 100, a multicast data 
transmission means such as a router 102, groups of clients 104-1,104-2,104-3 . . . 104-n with 
respective routers 106-1,106-2,106-3, . . . 106-n and the Internet 107 located between the routers 
of the groups of clients 104-1,104-1,104-3 . . . 104-n and the router 102); 

an output interface for providing signals for transmission to receivers, ([0033]), 
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Yaport discloses a data transmission server 100 for multicast data transmission, (fig. 2), [003 1], 
[0032], [0035], to recipients without acknowledgment, thus [0035], [0047]: the multicast 
distribution does not need confirmation: the server 100 and the method of multicast data 
transmission without chent-server sessions and acknowledgement). In addition Yaport teaches 
that information is transmitted by portions, known as protocol data units, [0044]. In addition, 
[0046], the control protocol data units of all data segments will allow to restore the missing data 
(portion of the data or PDU such as PDUCl, PDUC2) lost during the transmission. 

Yaport does not disclose an input interface, an output interface, and a controller as required by 
the claim. 

Cai discloses a server 118 coupled to a RAN controller 1 14 via a support node receives a first set 
of MBMS data fi-om an MBMS content provider, [0020], 

a controller ([0040]: fig. 1, the Radio Access Network further comprises Radio Network 
Controllers (RNC) 1 14), adapted to generate a notification on an upcoming multicast 
transmission, (a multicast service notification is transmitted to mobile stations, thereby 
informing members of the multicast group of an upcoming multicast sessions), responsive to a 
received file, to provide the notification through the output interface for transmission and to 
provide the received file for transmission, (notifying the mobile stations of incoming multicast 
data), without receiving acknowledgements from the receivers on whether they received the 
notification, to determine receivers designated to receive the multicast transmission that did not 
receive at least a portion of the data file and to attempt to deliver the data file to the determined 
receivers. 



Application/Control Number: 10/574,240 Page 33 

Art Unit: 2472 

Therefore, it would have been obvious to a person of ordinary skill at the time the invention was 
made to implement Yaport with the teaching of Cai so that clients can subscribe to a particular or 
selected multicast group at any time. 



Conclusion 

If attempts to reach the examiner by telephone are unsuccessfiil, the examiner's 
supervisor, William Trost can be reached on (571)272-7872. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 

Information regarding the status of an apphcation may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
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